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Abstract 


Good programming style is essential for writing computer programs which can 
easily be read and understood by human beings. Every part of a stylistic program 
communicates its intention and functionality clearly to its reader. Conventionally, 
programming style is a qualitative concept. However, for developing style based 
tools such as style checker, style analyzer etc., it has to be quantified. 

In this work an extensive study of C language’s coding styles has been done. 
This work is an attempt to quantify style rules using a specification language, 
C-Style Specification Language ( C-SSL). C-SSL is a simple and extendible lan- 
guage. A prototype style checker, C-Coding Style Checker (C-CSC), has also been 
developed for checking coding style of C language programs. 
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Chapter 1 
Introduction 


1.1 Objective 

In a software house hundreds of programmers produce millions of lines of code. This 
code is required to be compiled by number of different compilers and executed on 
variety of hardware and operating system. Normally a program will be written by 
few(one or two) programmers but will be read by many persons, many number of 
times during the different stages of software life cycle. The most important thing 
is that, normally, code will be maintained by a persons who are not its author. At 
times even testing will be done by somebody else. Under this kind of scenario it is 
imperative that every programmer should fallow certain rules or guidelines so that 
produced code will be more readable, portable, maintainable etc. 

Normally style rules/guidelines are laid down by some experienced programmers 
and made available in the form of some document written in some natural l ang uage. 
The task of ensuring that laid down rules are followed by every programmer in his 
program, is done by some experienced programmer or a software manager usually 
in a quality control group. He reviews the code, manually checking whether the 
program conforms to style rules. Sometimes these code-reviews get heated due to 
the varying tastes of the programmer and the software manager. 

The objective of this work is to study the issues pertaining to the programming 
style rules and tools based on them in particular for the C language. Goal is 
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to develop a mechanism for specifying style rules so that they can be used by 
various tools. 'Hus study reasons out the usefulness of the rules and describes 
the exceptions if any. A prototype coding style checker has been developed with the 
aim of automating the process of coding style checking. 


1.2 Related work 

Publications on programming styles often present either a set of style rules or 
descriptions about automated style analysis. Pretty printers [WC89] and code 
formatters concentrate only on the look of a program (only spaces and indentation). 
A number of style checkers has bmi written particularly for Pascal language. Most 
of these don’t provide much flexibility in specifying the layout. Papers and articles 
on style analysis have reported certain statistics about the programming style of a 
program but without any formal basis. These analyzers are basically style grading 
programs which quantify program characteristics thought to represent programming 
style and compute a style score as a weighted sum of factors. Importance of these 
factors remains a controversial issue. 

It is surprising to know that hardly any publications are found on automatic 
style checking of C programs in spite of its popularity and extensive usage. It is 
heard that some of the software houses use some tools for style checking but no 
information is readily available about them. Some of the significant developments 
of the past are 

lint : A statical checker for C programs[AT 92] 

LClint : A more powerful statical checker for C programs than lint [DEH94]. 
Indent : A C code formatter. It is a GNU’s free $oftware[Arc94]. 

Code-Check : A coding style checker for C programs [Cod90]. 

The Stanford Ada Style checker : A style checker for Ada programs[Wal91]. 
ASSESS : Evaluates stylistic factors of Fortran- 77 progx'ams[RS86]. 
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GEN+-+- : An analyzer generator for C++ programs[DE95]. 
IP-print : A prototype intelligent pretty printer for Pascal[WC89}. 


1.3 Overview 

Chapter 2 describes the concept of programming style. 

Chapter 3 gives a detailed account of various C coding style rules. 

Chapter 4 introduces a language for specifying style rules of C language. 

Chapter 5 describes a prototype coding style checker for C language. 

Chapter 6 concludes the work and suggests the future work that can be taken up in 
this area. 

Appendix A contains detailed grammar of C-Style Specification Language ( C-SSL ). 
Appendix B gives a sample style file. 

Appendix C gives a sample list style violation warnings generated by C-Coding Style 
Checker (C-CSC). 
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Chapter 2 

Programming Style 


The issue of programming style is as old as programming itself. There exists no gen- 
eral agreement on what constitutes a good style. There are several rules/guidelines 
which are followed by different groups. Several attempts to formally define them 
proved difficult, and met with a little success. Over a period, one general agreement 
arrived at is that, it is an elusive concept with intuitive elements, which make it 
difficult to define and quantify. 


2.1 Programming Style 

Some of the attempts to define programming style arc 

The elegance of style of a program is sometimes considered a nebulous 
attribute that is somehow unquantifiable; a programmer has an intuitive 
feel for a good or a bad pwgram . . .[EE85J 

Programming style brings to mind the ways that a creative programmer 
brings maintainability, testability, reliability and efficiency to the coding 
of a module [ J.85J . 

Above definitions show that it is a qualitative concept. The desirable qualities 
of a good program are as follows: 
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• Readability 

• Maintainability 

• Portability 1 and 

• Correctness 

There are certain other features such as 

• Reliability 

• Execution speed 

• Development time 

• Extensibility 

• Reusability 

• Memory size 

• Source code size etc. 

which are also considered as desirable properties of a programming style. But 
the importance of some of the features of the latter list has gone down with time 
and some others are implicitly covered by one or more features of the first list. This 
means that 

Programming style is a list of prescriptions, prescribed by experienced 
programmers, which help in achieving readability, portability, maintain- 
ability and avoiding certain programming traps and pitfalls. 

Following are the sample programming style rules: 

Source code is said to be portable if it can be compiled and executed on different machines, 
with the only change being the inclusion of possibly different header files, few alternate source files 
and the use of different compiler flags. Header files shall contain #defines and typedefs, which 
may vary from machine to machine. In general a new machine is a different hardware, a different 
operating system or a different compiler or any combination of these. 
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• All names shall bo meaningful, 

• Unconditional jumps shall lx* avoided. 

The rules which facilitate writing portable, maintainable code are free from 
debate . On the other hand those pertaining to other two are arguable and lack 
general acceptance. This is due to the inherent subjectivity of the concept of 
readability itself. A piece of code may be considered readable by one group of 
programmers whereas some other group may not feel so. 

if (account_bal&nce>0) { 

Hoof Trans++ ; 
process_trans(TransId) ; 
account .balance -» debit.amount; 

} 

Listing - 2.1a. 
if (acc.bal > 0.0 ) 

{ 

tcount++; 

process.trans (trans.id ) ; 
acc.bal -■ deb.amt ; 

} 

Listing - 2.1b. 

Different programmers may have different views on the listings 2.1a. and 2.1b 
shown above. It is difficult to rank one above the other and give reasons for doing 
so. The most difficult is to make others accept the ranking. This just gives an idea 
about the subjectivity of the issue. 

2.2 Coding Style 

Normally programming style and coding style are not considered different from 
each other. For the sake of better understanding of the under lying concepts it is 
advantageous to make distinction between them. Programming style is primarily 
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determined by the class of language or the programming model under consideration. 
For example: 

• Block Structured 

• Object Oriented 

• Functional 

• Logic etc. 

Concepts relating to programming style such as naming, program layout, robustness 
etc. can be discussed in a manner independent of any language, but certain other 
concepts like inheritance, backtracking, information hiding, side effects etc. don’t 
make much sense for one or more class of languages. 

Any two languages belonging to tine same class of language differ in syntax, 
semantics and features provided by them. For example external variables, static 
data, void pointer etc. are irrelevant for pascal, whereas any discussion on C coding 
styles is incomplete without them. This means that we can’t have the same set of 
style rules even for all the languages of a class. Hence we can define coding style as 

A set of rules , suggested by some experienced pwgramrners for a lan- 
guage, which help in achieving midability, portability, maintainability 
and avoiding pwgmmming and language’s tmps and pitfalls. 

Another way programming style and coding style can be defined as: 

All rules which help in achieving readability, portability, maintainabil- 
ity, and avoiding programming traps and pitfalls constitute programming 

style. 

Coding style of a pmgramming language is a set of programming style 
rules which can be defined in terms of syntax and semantics of the 

language. 

Following are the sample C coding style rules: 
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• Sub-words in an identifier name shall be separated either by an underscore or 
a capital letter as shown below: 

idniiijifv.immt or IdentifierName 

• Identifier names shall not start with an underscore. 

• Identifier names of ^defined constants and enumerated constants shall be in 
upper case. 

• Use of goto shall be avoided. 

• birak and rant in ut statement used inside for/while/do loop shall be com- 
mented. 

Defining coding style in this manner facilitates the addressing of specific features 
of a language to the fullest extent. It also provides a basis for the development of 
automatic tools based on them. 

2.3 Coding Standard 

For any programming problem there can be a number of equally correct programs 
providing its solution, but differing in some way from each other. This happens even 
when all of them are based on the same algorithm, and satisfy style rules. This is 
because of choices existing in the style rules and some may not follow certain rules 
due to the subjectivity of the rules. Programs can be formatted in more than one 
way. There are many naming conventions, statement orderings, commenting styles 
etc. If every programmer selects style options as per his taste then one will face more 
problems in understanding somebody else’s program. This finally gets reflected as 
revised project schedules and higher maintenance cost. These inconsistencies also 
devalue the entire group’s effort. It is unfortunate that these inconsistencies are 
called creativity by some groups. 

Now we can define coding standard as a set of cohesive coding style rules with 
the selected options if they exist as per the requirements and taste of a group. Here 
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group means a group of programmers working together on a project etc. This implies 
that coding standard may differ from group to group. In practice there exist some 
exceptions to the style rules. A coding standard document should mention them. It 
should also give the rationale behind them. 

Following are the sample C coding standard rules: 

• Variable names shall be in lower case only. Sub-words shall be separated by 
an underscore. 

• Identifier names shall not start with an underscore. 

• Identifier names of ^defined constants anti enumerated constants shall be in 
upper case. 

• goto statement shall not be used. 

• break and continm statement used inside for/while/do loop shall be com- 
mented. 

Coding standards can lie broadly classified into two classes [OC88]. 

Typographic: covers include level, indentation, line length, placement of com- 
ments, placement of blank lint's, use of embedded spaces, identifier length, 
module length, and format for type and data declarations. 

Structural: covers modularity, use of labels and gotos, use of named constants, 
use of include files, use of literals, method of type and data definitions, use of 
library functions level of nesting, control flow, information flow, operator and 
operand usage, and factors related to program complexity. 

With the development of formatting tools like Indent[Arc94] most of the typo- 
graphic factors are no longer considered crucial. One can easily reformat program 
as per his flavor using Indent or tools similar to it. This makes other factors more 
important because of the difficulties in automatically checking or achieving them. 
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2.4 Applications of Coding Styles 

Some of the useful tools which can be developed based on coding styles are: 

Style Checker: < 'becking programs for style violations. 

Code Converter: Converting a program to another program which satisfies given 
coding standard. 

Quality Workbench: An interactive tool for inspecting and editing programs. 
Given a style rule it shows parts of the program, on which given rule is 
applicable. 

Style Based Editor: Checking style violations as code is being edited/typed, and 
applying style transformations wherever possible, otherwise giving style viola- 
tion warnings. 

Style Analyzer: Given a set of style rules and associated weights computing a 

ised on this score a program may be categorized 
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Chapter 3 

C Coding styles 


C is the one of the most popular and widely used programming language. Most of 
the system software is written in Cor lately in its daughter C++ is being used. In 
the words of Andrew Koenig(Koe89] 

The C language is like a earring knife: simple, sharp and extremely 
useful in skilled hands. Like any sharp tool C can injure people who 
don't know how to handle it. 

C is full of traps and pitfalls. There are a number of ways one can unwittingly 
insert obscure bugs. A novice programmer may end up spending hours together 
debugging his code, which ultimately ends up in finding a simple typographical 
mistake. These are the reason for which we require good style rules and style based 
tools. 

Style rules can be classified into following classes 

• Syntactic Rules 

- Data definition and declaration rules 

- Function definition and declaration rules 

- Statement rules 

• Internal documentation rules 
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• Naming rules 

• Layout rules 

- Spacing rules 

- Indentation rules 

• General practices 

• Preprocessor rules 

Rest of the chapter describes an extensive set of style rules. Many of these rules 
can found in (Koe8«), [Tas78], (Al)lH)j, [Pik90], [HS8<>], [FSK94], and [Ous89]. This 
list also includes the rules which can’t be defined in terms syntax and semantics of 
the C language, at present. 

3.1 Syntactic Rules 

3.1.1 Data definition and declaration rules 

• Identifier doeiarations/definitions shall not span across lines. Preferably only 
one identifier shall be declare* 1/defined in a single statement. Multiple local 
identifiers may be declared /defined in a same statement provided inclosed 
block’s size is not more than a few lines. 


int 

foo_l , 

/* DISCOURAGED */ 


f oo_2 ; 


int 

foo_l; 

/* RECOMMENDED */ 

int 

foo_2; 

/* RECOMMENDED */ 


Option: Yes/Don’t care Benefits: Readability, Encourages documentation 

• Initialized variable definitions shall not be combined with uninitialized variable 
definitions in a same definition statement. There shall be only one initialized 
variable definition in a single statement. 
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Option: Yes/Don 7 ran Benefits '.Readability, Encourages documentation 

• Most significant dimension of an externally declared array variable or an 
argument shall not be specified. In case of array declared as argument, size of 
the array shall be passed as an argument. This facilitate passing of different 
size array on different invocations of the function. 

/* DISCOURAGED */ 

extern int foo.array [80] [100] 

char * 

foo.func (int array_arg[80] [100] ) 

{ 

} 

/* RECOMMENDED */ 

#def ine YDIM.SIZE 100 

extern int foo.arrayG [YDIM.SIZE] ; 

char * 

foo_func (int array. arg[] [YDIM.SIZE] , int xdia.size) 

{ 

* * * 

} 

Option: Yes/Don't care BenefitsiModifiability, Reusability 

• Most significant dimensions of an initialized array shall not be specified when 
array is fully initialized. It avoids change in the dimension when number of 
elements in the initialization list are modified. 

Option: Yes/Don’t care Benefits: Modifiability 

• Static identifiers shall be highlighted by initializing them. 

Option: Yes/No/Don’t care Benefits: Readability, Maintainability 
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• All identifiers whoso initial vahto is important shall be initialized at the time 
of definition. This probably saves few core dumps, which often occur due to 
uninit iafi/.<*d data. 

Option: Yes/ Don’t ran Benefits '.Reduces errors 

• All related identifiers shall be defined/declarod together, and a comment shall 
precede their declaration/definition. 

Option: Yts/ Don't ran Benefits: Readability, Maintainability 

• All statements of a particular type shall be declared /defined together. 

Option: Yts/ Don't van Benefits: Readability, Maintainability, tractability 

• Type definition for struct/umon/enum shall be combined with the correspond- 
ing definition. Type definition shall be present for corresponding pointer type 
as well. 

Option: Yes/No/Don't van Benefits: Readability, Maintainability 

• Initialized arrays shall not be defined in a local scope. If possible they shall 
be declared static. 

Option: Yes/Do mV van Benefits: Readability, Maintainability, Clarity 

• Expressions defining the array dimensions shall be simple ^defined expres- 
sions. 

#def ine HASH_TABLE_SIZE 100 
int hash.table [HASH_TABLE_SIZE + 1]; 

Option: Yes/Dont can Benefits: Readability, Maintainability 

• Type shall be specified for every identifier. Default int type feature shall not 
be used. 

Option: Yes/Don't van Benefits: Readability, Maintainability 

• No assumptions shall be made about the offsets of the fields within a structure. 
Due to alignment, field offset may vary from machine to machine. 

Option: Yes/Don’t can Benefits: Portability 

• struct, union, and enum shall be defined in a separate file. 

Option: Yes/Don’t care Benefits: Maintainability 
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3.1.2 Function definition and declaration rules 

• Function arguments in function definition/dedaratian shall not be cluttered 
within a single line. 

/* DISCOURAGED */ 
int 

foo.func (int argl , char arg2, float arg3) 

{ 

} 

/* RECOMMENDED */ 
int 

foo_func (int argl, 
char arg2, 
float arg3) 

{ 

} 

Option : Yes/ Da n't ran Benefits:li< adability, Maintainability, Documentability 

• Every function shall be defined as shown below. This provides a marker for 
function definitions. 

#def ine FUNCTION 

FUNCTION 

int 

foo.funct ion (void) 

{ 

} 


/* What is argl */ 
/* What is arg2 */ 
/* What is arg3 */ 
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Option: Yr s/Don V ran Benefits: Readability, scarchability 

9 Function prototypes shall hr declared for all the functions and they shall be 
defined with return type, and complete typed list of arguments. 

Option: Yes/ Don't ran Benefits: Readability, reduces interfacing errors 

• External declarations shall not he put inside a function. Normally many 
functions defined in a file will use same external function/variable. There 
fore all these external declarations shall he placed together. On the other 
hand if size of tin' function is less than 25 linesfone screen) then declaring 
externs locally will enhance readability at the cost of maintainability. 

Option: Yes/Don't ran Benefits'. Readability, Maintainability 

• struct /union /e n urn shall not be defined inside function or in local scope. 

Option: Yes/Don't ran Benefits:Maintainability, Consistent layout 

• Identifiers of type jlmt/doubh shall not be used with equality operator, or 
compared for equality. 

Option: Yes/ Don't ran BenefitsiPortabilily, Reliability 

• Identifier names shall not he redefined inside local scope. 

Option: Yes/ Don't ran Benefits: Readability, Maintainability, Documentability 

• Functions shall not have large number of arguments. 

Option: Number of args Benefits: Readability, Maintainability 

• main shall return an operating system defined value. It shall terminate 
through exit system call. This ensures the execution of at-exit functions and 
checking of program’s return status by shell scripts. 

Option: Yes/Don't can Benefits:Reusability, Reduces errors, Maintainability 

• Every function shall have preferably one exit point. 

Option: Yes/ Don't care Benefits: Readability, Maintainability 

• All functions returning pointer shall return NULL on failure. 

Option: Yes/Don’t care Benefits '.Reduces errors, Maintainability 
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• Function shall always return an integer value indicating it’s success or failure. 
However function returning a pointer shall return NULL to indicate failure. 

Option: Yes/Don’t can BenefitszMaintainability, Reusability 

• envp command line argument shall not be used. It may not available on some 
machines. 

Option: Yes/Don’t care. BenefitsiPortability 

• Command line argument, aiyi'[0] shall not be assumed to give the complete 
file name. On some machines it may contain only relative file name. 

Benefits : Portability 

• Function shall not return structure. Different compilers may use different 
conventions for passing and returning structures. This may causes a problem 
when libraries return structure values to a code compiled with a different 
compiler. 

Option: Yes/Don’t can Benefits: Portability 

• Size of a function shall not be more than 50 lines. 

Option: Number of Lines BenefitsiMaintainability 


3.1.3 Statement rules 

• Nested if statements shall be braced completely to indicate the nesting. 
/* DISCOURAGED */ /* RECOMMENDED */ 

if ( . . . ) if ( . . . ) 

if (...) { 

if (...) 

else 

else 


} 

Option: Yes/Don’t care Benefits: Readability 

• Assignment operators shall not be used inside a conditional expression. But 

in the following case doing so seems better. 
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while ((ch - getchar ()) !* EOF ) 

{ 

1 

Option: Yes/ Don 7 can Benefits: Readability, Maintainability 

• Embedded assignments shall not be used. 

Option: Yes/Don’t ran Benefits: Readability 

• Switch shall have a break statement for every case. When fall through feature 
is required then a comment shall be put. after the last statement to highlight 
the reason behind it. 

Option: Yea/Don't ran Benefits -.Maintainablity 

• Switch shall have default case and it shall be put at the last. 

Option: Yes/ Dan 7 rarr 'RenefitsiMaintainability, error detection 

• Conditional expressions shall not contain auto increment ’++’ and auto decre- 
ment operators. 

Option: Yes/ Don 't ran fSenefits: Readability, Maintainability 

• Conditional expressions shall not contain function calls. In the following case 
doing so seems better. 

while ( (ch * getchar ()) ! * EOF ) 

{ 

} 

Option: Yes /Do n 't cart Benefits: Readability, Maintainability 

• Index expression shall be a simple expression. It shall not have a assignment 
operator or a function call. 

Option: Yes/Don’t cair Benefits: Readability 
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• Pointer type identifiers shall not he used with other than binary *+’, and 
relational operators. Only pointers of the same type shall be compared. 

Option: Yt s/l)on't can Benefits: l friability, Maintainability, Readability 

• Actual arguments of a macro call shall not contain any auto operator, when 
a argument is used more than once in the replacement text, side effects may 
take place, which may result in obscure bugs. 

Option: Yes/ Don't ran Benefits: Reduces error a, Readability 

• Condit ional expression of a ternary operator shall be in parenthesis and nested 
ternary operators shall not not lie used. 

Option: Ms/ Don't ran Benefits: Readability, Maintainability 

• All type conversions shall be explicitly typecasted. This makes the program- 
mers intent dear. 

Option: Yes/ Don't ran Benefits:Maintainability 

• NULL shall never lx* used as end of string(EOS). EOS shall be ^defined as 
fdefin© EOS '\0' 

Option: Yes/ Don't ran Benefits: Readability, Maintainability, Portability 

• TRUE and FALSE shall he used only in the boolean context. They shall be 
defined as follows: 

typedef enum 

{ 

FALSE * 0, TRUE * 1 
} boolean; 

Option: Yes/ Don 7 can Benefits:Portability, Readability 

• Every system call and call to memory allocation functions shall be checked for 
a possible failure. 

Option: Yes/ Don’t care Benefits ’.Robustness, Maintainability 
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• No assumptions shall be made about the evaluation order. In the following 
code we can’t guarantee whether a[0] or a[l) will he set. 

i » 0; 

a[i] * b[i++3; 

Option: Yes/Don't ran Benefits: Portability 

• unsigned variables and char type variables shall not be compared with EOF. 
On some machines default char type may be unsigned. In such a case following 
code will be an infinite loop. 

char ch; 

while ((ch * getchar ()) ?■ EOF ) 

{ 

} 

Option: Yes/ Don’t ran Benefits '.Portability 

• No assumptions shall be made about the word size. Following code may not 
have a desired effect of clearing rightmost 3 bits. 

int num; 

num «... 

num &= 0177770; 

Option: Yes/Don't care Benefits: Portability 

• Values of a larger range shall not be assigned to an identifier having a smaller 
range. 

Option: Yes/Don’t care Benefits:Portability 

• Pointers of non basic data type shall not be cast to a pointer of of other type. 
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Option:! r s/Don't can Benefits: Portability 

• String constants shall not be modified. Following code may have an unex- 
pected behavior. 

string- ' ‘/dev/tty’?’ ' ; 
strepy (4string[8] , ttychars) ; 

Option: Yes/ Don't ran Benefits: Port ability 

• Expressions shall not contain more than one function calls. In the following 
code if both functions modify the same variable then program may behave 
different ly on different machines, due to the difference in order of evaluation. 
/* foo_l ft f oo_2 changes value */ 

result ■ foo_l () + foo_2 () + value; 

Option: Yes/ Don’t can Benefits -.Portability 

• Negative numbers shall not be used in integer division. This is not defined in 
the language. 

Option: Yea/ Don't can Benefits: Portability 

• There shall be at the most one statement in any line. 

Option: Yea/ Don't ran Benefits: Readability 

• goto shall be avoided as far as possible. 

Option: Yes/ Don't can Benefits ’.Readability, Maintainability 

• Normally only decimal constants shall be used. It is preferable to use hexa- 
decimal constants in bitwise operations. 

Option: Yes/ Don't can Benefits: Readability 

• Conditional test shall not default for non-zero. 

/* DISCOURAGED */ /* RECOMMENDED */ 

if ( foo<) ) if ( foo() != FAIL ) 
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3.2 Internal Documentation Rules 


Internal documentation or comments are an essential part of any long life program. 
It is required to describe tin* relationship between different code segments of a 
program. Comments shall be short and to the point. Comments and code shall not 
contradict each other. Good comments enhances readability and maintainability. 
Comments are of three types. 

Header comment: Used for a file header and function header. 

Paragraph Comment: Used before a block of code, describing a data structure, 
algorithm etc. 

One-line Comment; Used for describing an important line of code. 

• Comments shall be put at the following places. 

- User include files, describing its purpose. 

- End of file. 

- File header. It shall contain name of the authors, date of last modifica- 
tion, synopsis ol file contents, purpose of file, dependencies, modification 
history etc. 

- Fall through of a switch statement. 

- At the start of every block of code. This comment shall establish a clear 
mapping between the algorithm and the code. 

- static identifiers. 

— Global identifiers. 

- const identifiers. 

- Function arguments definition. 

- Non portable code segments. 

- Bit field definitions. 

~ goto statement. 
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- Label statement. 

- Hacked code segments. 

- struct , mum, and union definitions. 

- type definitions. 

- ^define constant definitions. 

• Function header. It shall contain purpose and meaning of arguments, de- 
scription of return value, dependencies, precautions, assumptions, side effects 
etc. 

• If a function is more than 25 lines (one screen) then it shall have a end of 
function comment as shown below. 

int 

f oo_f unc (...) 

{ 

} /* End of function foo.func (...) */ 

• If the body of if, else, switch, case, for, while, and do is more than 25 lines 
(one screen) then there shall be a comment at the end of the body as shown 
below. 

if ( condition ) 

{ 

} /* End of if ( condition) */ 
else 
{ 

} /* End of else ( condition ) */ 


switch ( expression) 

{ 


23 



case valut : 

{ 

} /* End of case ( value ) */ 

} /* End of switch ( expression ) */ 

while ( condition) 

{ 

} /* End of while ( condition ) */ 

do /* Begin of do ( condition) */ 

i 

} while ( condition) ; 

for ( . . . ; ( condition) ; . . . ) 

{ 

}/* End of for ( condition) */ 


3.3 Naming Rules 

Identifier names shall be mnemonic names, clearly indicating the obvious purpose 
for which they are used. They shall have some relation with the entity /concept they 
represents in a program. This relation ship shall be followed consistently in all the 
names used in a program. Well chosen names can make a program self documented. 

• Filename shall be in 11.3 format, where 11 is the length of full name and 3 is 
the length of extension. It shall be containing only letters, digits, underscore 
and dot only. 
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Option: Yes/Don't ran Benefits: Port ability 

• First 31 characters of all identifiers shall be unique in a compilation unit. 

Option: Yes/ Don't ran Benefits : Portability 

• First 6 characters of all global identifiers shall be unique. This is due the 
limitations of linker on some machines. 

Option: Yes/Don't ran Benefits -.Portability 

• Following file name extensions shall be used. 


file-type 

extension 

source 

X 

include 

.h 

assembly 

.asm 

assembly 

.inc 

include 


data 

.dat 


Option: Yes/Don’t care 'Benefits: Portability 

• ^defined constants, constant identifiers and enumerated constants shall be in 
upper case. 

Option: Yes/Don’t care Benefits : Readability 

• Identifier names shall contain a prefix indicating project, module, type, and 
scope. 

Option: Yes/Don’t care Benefits ’.Readability, Maintainability 

• Same name shall not be used for multiple purposes in different parts of a 
program. 

Option: Yes/Don’t care Benefits: Maintainability, Reduces errors 

• Escape character constants shall be ^defined 
Option: Yes/Don’t care Benefits : Readability 

• Function name shall have a prefix indicating return type. 
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Option: Yes/Don't care Benefits:Maintainability 

• Argument names shall have a prefix indicating their usage as input, output or 
both. 

Option: \es/Don t care Benefits'. Readability, Maintainability 

• Identifiers names shall not start with a underscore. Doing so may create 
conflicts with system defined names. 

Option: Yes/ Don't care Benefits: Maintainability, Portability 

3.4 Layout rules 

3.4.1 Spacing rules 

• There shall be a blank line before function body separating it from function 
name and argument definitions. 

Option: Number of lines Benefits: Readability, Encourages documentation 

• There shall be two blank lines separating data definitions/declarations from 
statements. 

Option: Number of lines Benefits: Readability 

• Code shall be organized in blocks. There shall be two blanks between two 
consecutive blocks. 

Option: Number of Ivies Benefits: Readability 

• There shall be no space around primary operators ‘ ->’ and ’ . \ 

Option: Yes/Don't care Benefits: Readability 

• There shall be no space between unary operator and it’s operand. 

Option: Yes/ Don’t care Benefits: Readability 

• Binary and Assignment operators shall have one space around them. 

Option: Yes/Don’t care. Benefits: Readability 

• There shall be at least one space or a newline after V and 

Option: Yes/Don ’t care Benefits: Readability 

• There shall be four/five lines between two consecutive function definitions. 

Option: Number of lines Benefits: Readability 
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3.4.2 Indentation rules 


• A if statement in the body of else shall be formatted as follows, 

if (• • •) if (.. .) 

else if (...) else 

{ 

if (...) 

} 

Option: Indent type Benefits: Readability 

• All block statement s if, switch, for , wh ile, do, and body of case shall be braced 
completely. 

Option :/nde7j/ type Benefits: Readability, consistent layout 

• Label shall start at column no 1 or at the next higher indentation level. It 
should be on a line by itself. 

Optio n: Indent type Benefits: Readability 

• Lengthy expressions shall be spilt onto multiple lines. They shall be paren- 
thesize appropriately to indicate the nesting, and desired operator precedence. 

Option: Indent type. Benefits: Readability 

• If for loop’s expressions (initialization, conditional and iteration expressions) 
are lengthy then each shall start on a separate line. 

Option '.Yes/Don't care Benefits: Readability 

• Initialized data shall be indented properly to indicate it’s structure. 

Option: Indent type Benefits: Readability 

• Size of indentation shall be 2 to 4 spaces. 

Option: Number of spaces Benefits: Readability 

• Only braces defining a function shall be on column 1. 

Option: Yes/ Don't care Benefits: Readability, Maintainability 

• Null body of a statement shall be indented properly. 

Option '.Indent type Benefits: Readability, Maintainability 
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3.5 General Practices 


• Indexing operator shall bo used only with array type identifiers and dereference 
operator shall not bo used for accessing array elements. 

Option: Yes/ Don t care Benefits: Readability, clear and non cryptic code 

• In general hard coded magic numbers shall not be used. They shall be replaced 
by enumerated constants! preferably) or ^defined constants. Depending on the 
context trivial constants such as 0, 1 etc. can be used as it is. 

Option: Yes/Don't care Benefits: Readability, Maintainability 

• Literal constants shall indicate the desired type. Only upper case letters shall 
be used in thorn. 

long long_var = 1L; /* RECOMMENDED */ 

float float _var = 0.0; /* RECOMMENDED */ 


long long_var = 11; 
long long_var - 1; 
float f loat_var « 0; 


/* DISCOURAGED */ 
/* DISCOURAGED */ 
/* DISCOURAGED */ 


Option: Yes/ Don't can Benefits ’.Readability 

• Include files shall not contain data definitions. 

Option: Yes/Don’t can Benefits : Reduces errors, Maintainability 

• Limits on the length or size of data structures, filenames, etc. shall be avoided. 
Benefits : Robustness, Reusability 

• Utilities processing files shall not drop null or any other non printable charac- 
ters. 

Benefits : Robustness, Reduces errors 

• Standard library function free shall be expected to modify the contents of the 
freed block. No reference shall be made to the freed block. 

Option: Yes/Don’t care Benefits '.Reduces errors, Portability 
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• Data which will not modified by the program shall be set using initialized 
definitions. It should be of declared as const type and static if possible. 

Option: Yes/ Don't can Benefits: Maintainability, Reduces errors 

• Non portable code shall be identified and organized in separate files. 
Benefits : Portability 

• Standard library functions shall be used instead of equivalent user defined or 
system specific funct ions. 

Benefits : Portability 

• Only ANS1-C shall be used as far as possible. Code non conforming to ANSI 
shall be organized in separate files. 

Benefits : Portability 

• Assumption about ASCII shall be avoided or char shallnot be assumed to be 
of 8 bits only. 

Benefits : Portability 

• Arithmetic operations shall not be replaced by equivalent shift operations. 
Benefits : Portability 

• No assumptions shall bo math* about parameter passing mechanism (size of 
pointers, parameter evaluation order, and size of parameters). In the following 
code ch may not return 2nd read character. This may happen due to the 
direction in which stack grows, or absence of a stack, or widening of arguments, 
or any combination of these. 

char 

foo (char chi, char ch2, char ch3) 

{ 

char ch4 * &(cl + 1); 
return (ch4) ; 

} 

ch * foo (getchar (), getchar ()); 

Benefits : Portability 
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• Backslash newline pairs shall bo used only in macro function definitions, and 
macro const ant definitions. 

Option: Y(s/ Don't can Benefits -.Readability 

• Strings shall not he split across lines using a backslash. 

Option: Yes/ Don't can Benefits: Readability 

• Size of a block of code shall not be more than 10 lines. 

Option: Number of lines Benefits: Readability 

• All global identifiers shall be defined in a single file. 

Option: Yes/ Don't can Benefits ‘.Maintainability 

• All identifiers shall be initialized prior to being passed as an argument to a 
function. 

Option: Yes/ Don't can Benefits :R, educes errors 

• All file inclusions shall be idempotent. Following shall be put in every include 
file to avoid multiple inclusions. 

#ifndef JFILEJMAME_H_ 
f define _FILE_NAME_H_ 

... /* Body of a include file */ 
tendif /* End of filename.)* */ 

• An open file shall be closed as soon as it is no longer required. 

Option: Yes/Don't care Benefits -.Maintainability 

• Dynamically allocated memory shall be freed as soon it’s usage is over. 
Option: Yes/Don't care Benefits '.Maintainability 

• Program shall not contain any compiler or lint warnings 
Option: Yes/Don’t can Benefits-.Maintainability 

• Size of source file shall not be more than 1000 lines. 

OptionzNumber of lines Benefits -.Readability, Maintainability 


30 



3.6 Preprocessor rules 


• ^define shall not he used for emulating typedef. If we have 
/* DISCOURAGED */ 

#define foo.rec struct foo_rec 

then suhse<juent redefinition will produce and warning where as redefinition 
of typedef will product' an error. 

Optio mYrs/ Don't ran Benefits: Reduces errors 

• Parenthesis shall he put around each of the macro arguments in the replace- 
ment text of the macro definition. This ensures that arguments are evaluated 
as desired, provided there are no side effects. 

Option: Yes/ Don't can Benefits: Reduces errors, maintainability 

• Macro definition shall not start with assignment operator. 

Option: Yes/ Don't ran Benefits: Reduces eri'ors 

• Macro definition shall not end with a This will avoid redundant null 
statements. 

Option: Yes/ Don V ran Benefits: Reduces errors 

• Replacement text of a macro constant/function shall be separated from the 
macro name by two or more number of spaces. 

Option: Indent type Benefits -.Reduces errors 

• Macro functions shall not have large number of arguments. 

Option: Number of argume&enefitsiReadability, Maintainability 

• Macros shall not be redefined 

Option: Yes/Don 7 can- Benefits: Maintainability 
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Chapter 4 

C-Style Specification Language 


C-style specification language ( C-SSL ) is a. language for specifying C coding stan- 
dard. In order to automate any process which requires coding styles, style rules 
have to be specified in some formal machine understandable manner. In a software 
house style rules are set by some experienced programmer(system manager), and 
followed by all the programmers. It is changed infrequently and marginally over a 
long period. Considering the above factor a high level approach is required for style 
specification. 


4.1 Design Goals 

Simple Syntax : Should not have large number of operators and constructs. 

Obvious Semantics: Specified rules should be self explanatory. 

Concept Basedi : Should be based on concepts related to programming style and 
the C language. 

Extendible : Should be able to add new style rules in the existing language 
structure. 
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4.2 Syntax and Semantics 


Coding standard specified in C-SSL is a sequence of C-SSL statements. Each state- 
ment describes a constraint on a concept or a language construct in an environment. 
Structure of grammar is shown in the following productions specified in BNF 1 . 


coding_standard : statement_list 

statement : environment { rule_list } 

rule : concept = constraint ; 

I group = { rule_list } ; 

Following is the list of environments: 

• code-file : A unit of compilation 

• pp : Preprocessor 

• func-def : Function definition 

• func-decl : Function declaration 

• statement : Executable statement 

• comment : 

• constant : Numerical, character and string constants 

• expression : 

• ddd : Data declaration and definition 

• op : Operator 

• name : Identifier names 


1 Backus Normal Form 



Groups are basically provided to group certain set of rules so that they can be 
specified by a single statement. Following is the list of groups: 

• comment : 

• size : 

• position : 

• ddd : 

• macro.const : ^defined preprocessor constant 

• macro. func : ^defined preprocessor function 

• include : File inclusion directive. 

• PP-if • #*/. #ifndef, #ifdef 

• hash : Preprocessor’s character. 

• if : if statement 

• switch : switch statement 

• loop : while , for and do statement 

• index.expr ; Index expression. 

• logic.expr : Logic or conditional expression 

• call.expr : Gall expression 

• block : Block comment. 

• struct : struct /union 

• array : 

• enum ; 
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Following is the list of constraints. 2 . 

• mask : A option value Yes/No/Don’t care 

• munber : An unsigned integer used for specifying sizes, number of lines, 
number of spaces etc. 

• string : 

m type -list : List of data types. Considered types are void, char, uchar (unsigned 
char), short, ushort (unsigned short), int, uint (unsigned int), long, ulong 
(unsigned long), float, double, struct, union, array, enum, pointer, and 
uscrtype (type.de Jed type). 

• stmntJist : List of statements. sysJnclude, userJnclude, macro-func, 
macro-const, typedef, struct (definition), enum ( definition) , extem-var, ex- 
tern static. June, static-var, globaLvar, junc-defi static Junc-def are the type 
of statements. 

• indent-option Used for specifying type of indentation. It consists of posJype 
and number. posJype is used to indicate the relative position. It can be one 
of the following: 

— spaces : 

— newline : 

— newline spaces : Last + spaces 

— align : Align with the current indentation. 

— alignspaces : Last + spaces 

— argstart : Argument start position 

— argstarLspaces : Last + spaces 

— indexstart : Index expression start position. 

— indexstart-spaces : Last + spaces 

2 Upper case names are the tokens of C-SSL 
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- calLstart : Function call’s argument start position. 

— call-start -spaces : Last + spaces 

• opJist : List of operators. 

• opnameJist : List of operator names 

• op .entry : It consist of operator, n?im&er(prefix space) and number (suffix 
spaces) 

Complete grammar of C-SSL along with descriptions of concepts and constraints 
is given in the Appendix A. 
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Chapter 5 

C-Coding Style Checker 


Style checking of C programs is a process which extends the standard grammar to 
include spaces, newlines, textual position of sentences, and placement of comments 
and restricts some of the sentences of the language. C - Coding Style Checker 
(C-CSC) is a prototype style checker for the C language programs. It uses style 
rules specified in C-SSL. Figure 5.1 shows the process of style checking. 

5.1 Implementation 

C-CSC performs two passes over the given input program. 

Pass-I Preprocessing 

• Builds macro definitions. 

• Filters conditional compilations statement. Part of the code which will 
not be compiled is put inside comments. This way textual positions of . 
statements remains unchanged. 

• Macros are not expanded. 

Pass-II Parsing and style checking. 

• Builds symbol table 

• On recognizing productions makes a call to style checking functions. 
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Style Specification Statements 



C Coding Standard 


1 


/ 

c-csc 


C Program 





Style Violation Warnings 

Figure 5.1: Style Checking Process 
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Style checking functions perform necessary checking depending on a rule if 
that rule is set in the given coding standard. On detecting style violations 
appropriate violation messages are generated. 

5.2 Usage 

C-CSC accepts two command line arguments, a coding standard file and a C program 
file. 

<prompt : > ccsc CCoding Standard File> <Program File> 
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Chapter 6 


Conclusions 

6.1 Conclusions 

This work is an attempt to develop coding style based tools. Although C-SSL 
and C-CSC are meant exclusively for the C language but the methodology and the 
concepts discussed in earlier chapters can be applied for other languages as well. C- 
SSL presents an easy way of specifying coding styles. Using it we can specify most 
of the popularly used style rules. It can easily be extended to incorporate other 
rules which are presently not covered. Simple and readable statements of C-SSL 
can serve as an on-line reference in addition to the voluminous documents. C-CSC 
is a prototype style checker. It can check a subset of GNU coding standard. It 
doesn’t perform any kind of data flow analysis. Very few style rules require data 
flow analysis, but without them style checking can’t be complete. 

6.2 Exceptions 

• C-CSC assumes that input program is free from compilation errors and is 
written in ANSI C. 

• Backslash newline pairs shall not be present within identifier names, keywords, 
constants, and ‘/*\ 
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• Old style argument declarations not supported. 

• Include files are searched in /usr/include and current working directory only. 

• Trigraph sequences, and '##' operators are not handled. 


6.3 Future Work 

Certain programming style rules are qualitative. They can’t be checked algorith- 
mically with presently available techniques. Further work can be done to define 
these rules in terms of language’s syntax and semantics, so that they can be checked 
automatically. 

We can check the presence or absence of a comment. Interpreting the meaning of 
comment text, or its relevance to the code is a natural language understanding prob- 
lem. But certain approximate techniques can be developed based on the presence 
of identifier names and/or corresponding entity names represented by identifiers in 
a program, in comment text. C-CSC checks only a single program file at a time. 
A good style checker should understand the concept of project or module. This is 
required for checking consistency of coding styles in all the files of a project/module. 

It is desirable that consistent naming conventions shall be followed. There will 
be a number ways an identifier can be named meaningfully. Further studies can 
be made to understand naming conventions. It may be possible to establish some 
relations between identifier names and object names so that their meaningfulness 
can be checked by automatic tools. 
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Appendix A 
C-SSL Grammar 


Token names are in upper rase, 

style : style_rule_list 


mask: 

YES 
i 10 


case-option: 

UPPER 
I LOWER 
f MIX 


// Relative position with respect to the previous token/ sentence 
pos.type: 

SPACES 
I NEWLINE 
I NEWLIMEJSPACES 

// Align with start column of the statement/current indentation 
I ALIGN 

I ALIGN .SPACES 

// Align with start column of arggmnents 
I ARGS-START 
I ARGS_START_SPACES 

// Align with start column of index expression 
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I IIDEXJSTART 
I INDEX -START-SPACES 

// Align with start column of call's first argument 
I CALL .START 
I CALL-START-SPACES 


indent .opt ion: 

•(' pos.type \» NUMBER *)* 


style.ruleJ.ist : 

style jruleJList style-rule 
I stylejrule 


style-rule : 

If A Compilation unit 
CODE-FILE »{' file_rule_list »}» 

// Preprocessor 

I PP * { ’ pp.ruleJ.i8t ’}’ 

// Function definition 
I FUNC.DEF *{’ func.defjruleJ.ist »}• 

// Function declaration 
1 FUNCJDECL >{• func_decl-rule_list »}» 

// Executable statements 
I STATEMENT *{* stmntjrule_list >}’ 

I COMMENT *{* comnt jruleJList »}' 

// Literal and string constants 
I CONSTANT >{* const jrule-list *}» 

I EXPRESSION »{» expr-ruleJList ’}’ 

// Data definition and declaration statements 
I DDD *{» dddjrule-list »}* 

// Operator 

1 OP . »{* op-rule J-ist ’}’ 

// Identifier names 
I NAME ' name jruleJList 
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filajruleJList: 

filejruleJlist ’ ; ' f ile„rule 
I file-rule 


fila_rule: 

COMMENT *{• file.comnt_rule.list >}' 

I SIZE '{ ' t ile.aize.xule.list 
// End ol file shall be commented 
I COMMENT JEOF '*> aask 
// Comment every block of code 
I COMMENT JBLOCK aask 
// Min size of block vhich shall be commented 
I COMMENT JBLOCK J5IZE •»* NUMBER 
ft File shall have a header comment 
I HEADER ’=• aask 

ft Backslash newline pairse only in macro definitions 
i BSJL aask 
/* Terminate via exit */ 

I NO .RETURN '■* aask 

/• Exit operand shall be OS define value */ 

I EXIT.TO.OS *«> aask 
/* Idempotent file includes */ 

I IF.INCLUDE mask 
1 LINT .WARNINGS »■* mask 
I REDEFINEJSTD .NAMES * = * mask 
// Type of info file header shall have 
I HEADER .FORM AT »(* stringJList >)• 

I TABWIDTH *=’ NUMBER 
1 INDENT .WIDTH »■* NUMBER 
ft Maximum lines in a file 
I MAX-SIZE » = > NUMBER 

f( Number of blank lines separating two function definitions 
I FUNCJ5EP ABATOR ’=’ NUMBER 
1 BLOCK JSEPARATOR ’=’ NUMBER 
// Max nimber of non blank lines 
I MAX JBLOCK JSIZE **» NUMBER 
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N 

// Order of statements in a compilation, unit . 

// Order value shall bo defined for all statement types. 

/ / If order is not specified of some statement type then, 

// occurance of that type of statement will be considered as 
// a style violation. 

// 

I ORDER 'a' * (* stmnt. order ')’ 


file.comntjruleJ.ist : 

f ile.comnt jrule Jist f ile.comnt.rule 
I f ile.comnt .rule 


f ile.comnt jrule : 

I EiD mask 
I BLOCK »*' mask 
I HEADER mask 
I ALL »■* mask 


filejsize jrule Jist : 

file.sizejruleJist * file.s ire jrule 
1 file_size_rule 


filejBize jrule : 

CODEJFILE '=> HUMBER 
I BLOCK ’=* IUMBER 
I I ID EXT IUMBER 

I TABWIDTH >*» IUMBER 
I FUICJSEPARATOR '=’ IUMBER 
I BLOCK .SEPARATOR ’=’ HUMBER 


stmnt_order : 

stnmt_order ’ , 1 ’(’ stmnt.type NUMBER ’)’ 
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I »(’ stant.type IUHBER *) ’ 


stamt.typa : 

// Systea include 

SYS.ISCLUDE 

// User defined include 
I USER JC1CLUDE 

// Macro constant 
I MACRO.COIST 

// Macro function 
I MACRO JFUXC 
I TYPEDEF 

// struct/union definition 
i STRUCT 

// enua definition 
I EKUM 

// extern identifier declaration 
I EXTERI.VAR 

// extern function definition 
I EXTERIJFUIC 

// static function declaration 
I STATIC JFUMCJDECL 

// static identifier definition 
I STATIC.VAR 

// Global identifier definition 
I GLOBAL.VAR 

// Function definition 
I FUMCJDEF 

// static function definition 
I STATIC JFUMCJDEF 


func.decljrule.list : 

funcjdecljrule _List ’ ; ’ func.decl.rule 
1 funcjdecljrule 

> 
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funeJeel-rule: 

POSITION *{' func_decl„pos_rule_list 
// Dihnt argument names and types 
I DEFJtRG JAMES *»• mask 
I MAX _ARGS ><*> NUMBER 
1 MAX JLRGS.PERXI1E '=> NUMBER 
I START .POS indent. option 
I MAMEJPOS *** indent .opt ion 
I ARGS.STARTJPOS ’ = ’ indent.option 
// Continuation position ot arguments 
I ARGS.COITJPOS indent.option 

// Disallowed return types 
I B AD JRET .TYPES ’(' type.list ')> 

ll Specify return type 
I DEFJET.TYPE »«’ mask 

// Spaces between function name and open parenthesis 
I BINDJ3PACES ' = • indent.option 
I REDEFINE JAMES ' = » mask 
// Redefine standard names 
I REDEFIIEJSTD JAMES mask 

// Use variable length arguments 


I USE.VARARGS 

I 

mask 

typeJList : 


typeJList ’ , 

’ type 

1 type 

A 


type: 


VOID 


1 CHAR 


1 UCHAR 

// unsigned char 

1 SHORT 


1 USHORT 

// unsigned short 

1 IHT 


1 UIIT 

// unsigned int 

I LONG 
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1 UL01G 
I FLOAT 
i DOUBLE 
I STRUCT 
i UVIQ* 

I EIUN 
I USERTYPE 
I ARRAY 
I PTR 


// unsigned long 


// typedefd type 


// pointer 


func.decl_pos jrule -list : 

func.decl.pos-ruleJ.ist *;» func.decl.posjrule 
I funcjdecl.pos_rule 


1 uncjdecl_pos jrule : 

ARGSJSTART *=' indent .opt ion 
I ARGS.COVT *»' indent .opt ion 
I START *** indent .opt ion 
i VANE indent .opt ion 


funcjfef jruleJist : 

func.dof jrule Jilt * ; * func-defjrule 
I funcjdef jrule 


funcjdef jrule: 

POSITION '{' func.def _pos jruleJist >}> 
t SIZE ’{ ’ func_daf_size_ruleJist ’ } ’ 

1 COMHEIT ’{* lunc.def -comnt jrule Jist ’}’ 

// Data declaration/definition rules 
I DDD »{> func.def_dddjrule.list *}» 

// Prefix string for definition 
I PREFIX '=’ STRING 
I HAX.ARGS ' = ' NUMBER 
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I USE.EIVP •=* Buk 
I DECL..EXTER1 .VARS '=* mask 
I DECL JEXTERX JFUICS >*' mask 
// Define struct/union 
i DEF .STRUCT mask 

I DEFJNUM *=* mask 
I DEF.TYPEDEF * = * mask 
I DEFJSTATIC.VARS **' mask 
) RE0EFX1E JAKES '=» mask 
I REDEFINE JTD JANES mask 

I BAD JET .TYPES ’■* *(• typa.list ')' 

I DEF JET .TYPE '«* mask 
I SINGLE JETURN mask 

I END .COMMENT *■* mask 
I END .COMMENT JODY -SIZE ’=> NUMBER 
/* Function header comment */ 

I COMMENT JEADER ’ = ’ mask 
I COMMENT .ARCS '=* mask 
I COMMENT JTATIC.VARS mask 
I COMMENT JLOCX *«’ mask 
I MAX-SIZE *«* NUMBER 
I MAX JLOCKJSIZE NUMBER 

I DECL JSEPARATOR J5 I ZE NUMBER 

I BLOCK JSEPARATORJIZE NUMBER 

I MAX -ARGS JERJLI1E NUMBER 

I ARGSJSTARTJOS »■» indent .opt ion 
I ARGS.CONTJOS **' indentation 
// Start column of return type 
I START JOS ’ = ’ indent .opt ion 
I NAME JOS indent.option 

I OPEN .BRACE JOS ’ = ’ indent.option 
I CLOSE JRACE JOS indent.option 

// Start column o f local declarations/definitions 
I DECLjSTARTJQS ’ = » indent.option 
I STATEMENT JOS ’ = ’ indent.option 
I BINDJSPACES ’ = ’ indent. option 
I USE.VARARGS mask 
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funcjdef .pos jrul e.l i at ; 

func.def.posjruleJ.iat * ; * func.def.pos.rule 
I func.def poa jrule 


funeral .poa jrul • : 

// Start column of return type 
START indent .option 
I ARGSJSTART '»* indent. option 
I ARGS.CORT ’ = 1 indent .option 
1 IANS indent .option 
I OPEN .BRACE •«' indent .opt ion 
1 CLOSE .BRACE *»' indent.option 
I DECL-START indent.option 
I STATEMENT JP0S '=• indent.option 


f uncjdef jsiza-rule J ist : 

func.def.sizejrule.liat func.def_size.rule 
I func.def .sizejrule 


funcjdef jaizejrule: 

FUNC NUMBER 
I BLOCK *■* NUMBER 
I DECLjSEPARATOR HUMBER 
I BLOCK .SEPARATOR ' = * HUMBER 


funcjdef .comnt jruleJList : 

f uncjdef .comntjruleJiat ’ ; ’ func_def .comnt jrule 
I funcjdef. comnt jrule 


funcjdef .comnt jrule : 

ALL ’=’ mask 
I END '** mask 
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1 HEADER ’=’ mask 
1 BLOCK 'a* mask 
I STATIC .VAR '=■ mask 
i ARGS ’=’ mask 


funcjdafjddd.rulaJ.ist : 

func-daf .dddjrule JList * ; * func.def.dddjrule 
I func.daf .dddjrule 


f uncjdef _ddd jrule : 

EXTERH.VAR *** mask 
I EXTERIJFUIC *»» mask 
I RET.TYPE *■* mask 
I STRUCT ’=’ mask 
I EIUH »** mask 
l TYPEDEF '=* mask 
I STATIC _VAR ’«* mask 

// Variable number of arguments 
I VARARGS **' mask 

// Sets every thing in the above list except return type 
! ALL >»> mask 


pp_rule_list : 

ppjrule_list ’ ; ’ ppjrule 
1 ppjrule 


pp .rule : 

HACRO.COHST ’ { ’ macro.const jrule JList 
I MACRO JFUMC »{* macro June jrule Jist ’} ' 
i IICLUDE ’{> include Jrule JList ’}’ 

// #if , #if def , #ifndef 
I PPJEF >{» pp_if jrule JList '}’ 

// Rules pertaining to # and directive name 
I HASH '{» hash jrule J.ist ’}’ 

central LJBRAR> 

1.1. T., KANPUR 

tab A.UUL7 
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haslurule Jist : 

hashjrule Jist * hashjrule 
1 hashjrule 


hashjrule: 

HASH JPOS indent .opt ion 
I DIRECTIVE J»OS indentation 


include -Tula Jist : 

includejrule Jist * ; * include j-ule 
i includejrule 


includejrule; 

I COMMEST »«» mask 
I RELATIVE .FILE JAKE '** mask 
I MAX_IESTED_mCLUDE *■* HUMBER 


nacro.conetjruleJ.ist : 

nacro.const jruleJist ’ ; * macro.const jrule 
I nacro.const jrule 


nacro.const jrule : 

l EMITATES.TYPEDEF > = * mask 
I SEMI COLOR .AT JEH D ’=’ mask 
I ASSIGH-ATJSTART *■* mask 
I BRACKETED -DEF * = * mask 
// Redefine nacros 
1 REDEFIIE '*• mask 
I COHMEHT '=» mask 
// Size in number of lines 
I MAX-SIZE '■» HUMBER 



ucro.func.rul* .list : 

■ncro.funcjrulsl.ist aacrojfuncjnile 
I macro.func.rul* 


Mcro Jfunc jruls : 

// Arguments in replacement text shall in parenthesis 
I BRACKETED. ARCS *«• aask 
// Replacement tsxt shall in braces/parenthesis 
I BRACKETED _DEF ’■* aask 
I SEMICO LOUT .END *-* aask 
I MliJIRGS HUMBER 

I HAXJLRGS '■* HUMBER 

// Rsdsfins macro functions 
I REDEFIIE aask 

I COMMEIT '«• aask 
// Position of baclslash 
I BSHLJPOS *■* indent .option 
I COITJPOS indent .opt ion 

I START JPOS *«* indent .opt ion 
I ARGS .START _POS ’«» indent .opt ion 
I ARGS. COITJPOS '«• indent. opt ion 


ppjLf_ruleli#t: 

pp_if .rulelist *;* pp.if jrule 
I pp_if jrule 


pp_if jrule: 

// use preprocessor's defined operator 
I USEJDEFIMED > = > mas k 
// comment Velse and telseif 
I COMMEHTHLSE • = ' # ask 
I COMMENT JSNDIf > = > nas k 

// Min body 8 i z « 0 f #if, # e i S e and #elseif to have comment 
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I E1DI F.CQHHEBT JBOD Y -SIZE -»> IUMBER 
f MAX_»ESTED_IF *■' HUMBER 


const jrule JList : 

const jruls J.ist ' ; • const jrule 
1 const jrule 


const jruls: 

// Uss only cpltnl lsttsrs in litoral costants 
CAPITALIZE *■* nnsk 
// Uss only deciaal constants 
I DECIMALS >■* nask 

// uss hexa-decia&l constants in bitwise operations 
1 HEX-II JBITJSTATEHEBTS mask 
// All character constants shall be #defined 
I DEFIBED -CHAR-COASTS mask 

// List of magic constants which can be used as literal constants 
I MAGIC-LIST *■* »(* string JList ’)’ 

// Uss angle constants 
I HAGIC.CQBSTS '■* mask 


string JList: 

string JList *,* STRIMG 
i STRUG 


stant jruls JList : 

stant jrule J.ist * ; * stant jrule 
I stnntjrule 


stant jruls: 

IF »{* if jrule J.ist »}» 

I SWITCH *{* switch jrule JList 
// for, do ajnd while loops 


54 



i LOOP l©opjrui*-li#t 

J COHN EAT '{ * stmat.xoant.ruleJ.i8t »}» 

1 STATEN EATS PER XI IE IUHBER 

I USE GOTO •»> uik 
| CONHEKT.COTO *«» Mtk 

// spaces between if /swicth/for/while and following parenthesis 
I BIRD-SPACES »■* indent. option 
// spaces between return and following parenthesis 
I RETUR* BIRD -SPACES *■' indent. option 
// Put return argument in parenthesis 
I BRACKETED RETVRA '** mask 
// use eabeded assignments 
I MULTIPLE ASSIGRS *■' Mask 
I LABEL-START .POS *«' indent.option 
// label shall be on a line by itself. 

! EMPTY .LABEL JLIXE »■» mask 
i COMMERT JROI JPORTABLE mask 

I COMMEIT.BIT-STATEKERTS •«* mask 
I IULL-IS.PTR *** mask 

// use default type promotion/typecast rules 
I DEFAULT .TYPECAST mask 

// typecast pointer other than to/irom void or signed and 
// unsigned of same types 
1 TYPECAST JPTR mask 
I MULTIPLE JTJIC.CALLS *«* mask 
// Assign higher range vars to lower range vars. 

I CHECK JtARGE »■» mask 
// use negative number in integer division 
i REG ATI VE-I *T _D I V »** mask 
I lULLJfOTJEOS ’ = ' mask 
1 CHECK JSYS.CALL *■* mask 
// check call memory allocation functions 
I CHECK JfEK.CALL *■» mask 
I BRACED -STATEMENTS *»* mask 
// if, switch, for, do, while shall have a 
// comment at end of their body. 

I EID-COMMEYT »■’ mask 
I EID.C0MMEITJB0DYJ5IZE *■» mask 
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I QPEI JRACE JPOS >*> indent .opt ion 
I CLOSE JBRACE JPOS *■' indent.option 
| IULLJBODY JPOS *«* indent.option 
{ COMMENT JULL.BOD Y mask 

I MAX-SIZE *■* IUMBER 


stamt.coantjruloJ.iat : 

GOTO •«* aaak 
I IOMJPORTABLE aaak 
I BXTJSTATEMEITS ’«* aaak 
I BID aaak 
I BULL JODY ’■* aaak 


switch-rule Jist : 

switch .ruleJist * ; • switchjrule 
I switch .rule 


switch jrula: 

// usa fall through faatura 
I FALL-THROUGH aaak 
I COMMIT JFALL.THROUGH »■* aaak 
// Body in bracas always 
I BRACED '■* aaak 
1 OPEI J RACE JPOS *»' aaak 
I CLOSE JRACE J»OS *■» aaak 
{ EKD.COMHEIT *■» aaak 
I EID.COHMEITJBODY-SIZE * = * aaak 
I MAXJSIZE **» HUMBER 
I BIRD .SPACES '■» indent .opt ion 
// use default always 
I DAFAULT.CASE *■* aaak 
// default shall be the last condition 
I DEFAULT.CASEJLAST »■* aaak 
// Body case shall be be braces 
I BRACED .CASE *■» aaak 
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// Max number of hnti of case body 
I HAX-CASEJ5IZE •«* Mask 
1 CASE POS aask 
i STATEMEITJPOS **' Mask 
// case condition shall be on a line by itself 
I EKPTYXASE.il IE aask 

// number of case conditions per line 
t CASES .PERXIIE »*' IUMBER 
I COMKEITXASE ’«• mask 


loop-rule-liat: 

loop-rule .list ’ ; ’ loopjrule 
I loopjrule 


loopjrule : 

// Body shall always be in braces 
BRACED aask 
I EIDXOHHEIT '■* aask 
i B1DX0MMEMT .BODY .SIZE IUMBER 

I MAXJSIZE *■’ IUMBER 
I COXKEITJBREAK *■* aask 
I CQMMEITXQITXIUE *■* mask 
I OPEI JBRACE -POS *** indent. option 
I CLOSE-BRACEJPOS '»* indent-option 
1 IULLJBODYJPOS »*' indent-option 
I CQMMEITJfULL-BODY ' = ' aask 
1 BXXD.SPACES >*' indent-option 
i STATEHEITJPOS ’ = * indent-option 
// max length in chars of for's initial; ization, condition and 
// iteration statement . If expr is lengthier than it the 
// it shold be split over multiple lines. 

1 MAX_FOR_EXPRiEIGTH *■* IUMBER 


if .rule-list: 

ifjruleJList ' ; * if .rule 
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if .rule 


if .rule: 

BRACED mask 
I ERD.CQHHERT '*> mask 
1 ERD.CQHHERT -BODY .SIZE >«• RUBBER 
I MAXJSIZE *■* RUBBER 
I OPER -BRACE POS indent .opt ion 
I CLOSE BRACE POS indent .option 

I RULL .BODY POS *»• indent .opt ion 
I COMMEVT , JULL .BODY mask 
I STATEHEITJPOS *■* indent. opt ion 
I BIRD. SPACES *■' indent .opt ion 
1 BRACED JESTED.IF **' naak 
I ELSE.IF.SPACES *«* indent .option 


exprjruleJLiat : 

expr jruleJList ' ; * exprjrule 
I exprjrule 


exprjrule: 

INDEX index.exprjrule.liat ’}* 

I LOGIC '{* logic.expr jrule Jliat 
I CALL call.expr jruleJList *}’ 

// long/multiline expressions shall be split after op/operand 
I SPLIT .AFTER • = ’ OPERARD 
I SPLIT .AFTER '*• OP 
I CORTJPOS *■* indent-option 

// Valid operators with pointer type variables 
I PTRJJPS »** •(' opJList ')’ 

// ptr shall be compared with HULL or ids of identical ptr types 
I IULLJPTR.COMPARE mask 

// EOF shall be compared with signed type only 
I SIGHED JEOF.COMPARE ' = ’ mask 
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// *»x operators par lint 
I MAX. OPS.PER LIRE *«> DUMBER 
// mx operator* per expression 
\ HAXJ3PS.PER.EXPR DUMBER 


opJlist : 

opJist *,* opcode 
I op. code 


index.exprjrule.liat : 

index.expr.rule.list *;* index .exprjrule 
I index. exprjrule 


index.expr jrule: 

BAD. OPS '** '(' op .list *)’ 
I SPLIT-AFTER '** OP 
I SPLIT-AFTER '»* OPERAID 
I CORTJPOS indent .opt ion 

I BRACKETED mask 


logic.expr jrule JLiat : 

logic.exprjruleJ.ist * ; * logic. exprjrule 
I logic.expr jrule 


logic-expr_rule: 

BADJOPS *«’ '(> opJist »)’ 

I SPLIT-AFTER *»* OP 
I SPLIT .AFTER '»* OPERAID 
I COITJr’OS indent .opt ion 

// conditional expression must have at least one relational op 
I DEFAULT-FAIL *•> mask 
I BRACKETED mask 
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call.axpr jrula JL iat : 

call.axpr xulaJ iat call.axpr xula 
I call.axpr xula 


call.axpr jrula: 

SPLIT JIFTER RUBBER 

I COIT.POS ' = * indant option 

// Spacaa batwaan function naaa and paranthaais in function call 
I BIRD-SPACES ’■ ‘ indant option 

// Diaallouad ops in call axpraasion 
l BAD. OPS *(' op.liat ')* 

! HACRO.CALLJUD.QPS '(* opJLiat »)’ 

1 CAST-NULL *■* auk 
I CASTJlRGS Hack 


connt_rulaJLiat: 

count jrulaJLiat ' ; ' count _rula 
I comntjrula 


coant jrula : 

BLOCK block.coant jrulaJLiat »}• 
I START JSPACBS *■* NUMBER 
1 END-SPACES NUMBER 
I START-CASE *** caaa.option 
I TEXT.CASEJDPTION ’ = ’ caaa.option 
I INDENT .TEXT >*> aaak 


block-count jmlaJliat : 

block.conntjmlaJ.iat ’ ; ’ block.comnt_rule 
I block-connt_rula 


block-count jrula : 
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STARTJPOS , = > indent .option 
( TEXT-STARTJPOS , = > indent-option 
I CONT-POS > = > indent-option 
I ENDJPOS * = * indent.option 
I PREFIX-STRING > = > STRING 
1 SUFFIX-STRING >=> STRING 


ddd-rnle -list : 

ddd-rule-list * ; 9 dddjrule 
I ddd-rule 


ddd-rnle : 

STRUCT >{> strnctjrule-list >}> 

1 ARRAY , { > arrayjrnle-list ) } > 

I ENUM >{> enumjrul e-list >}* 

// max lines in decl/def inition statement 
I MAX.LINES > = * NUMBER 
I MAX.VARSJPERXINE > = > NUMBER 
// initialize identif ers 
I INIT-VARS mask 
1 INITJSTATIC-VARS mask 

// Every decl/def inition shall have one type of void, char, 
// short, int, long, float or double. 

I DEFAULT -INT-TYPE »=> mask 
I COMMENT-GLOB AL-VARS »s» mask 
I COMMENT -STATIC-VARS mask 
// comment const declaat ions /definitions 
I COMMENT-CONST ’ = > mask 
I STARTJPOS , = > indent -opt ion 
I CONTJPOS , = > indent -opt ion 
// Portable #define types shall be used. 

I PORTABLE-TYPES , = > mask 

// All typedefs shall be defined in a separate file 
1 TYPEDEFJFTLE mask 

// All struct /unions shall be defined in a separate 
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I STRUCT JFILE » = » mask 

// Humber spaces between * and id in pointer decl/def inition 
I PTR-BINDjSPACES ’ = ' indent.option 


enum_rule_list : 

enum_ruleJList ’ ; ’ enum_rule 
I enum_rule 


enum_rule : 

ENUH -BOOLEAN ’=' mask 
I COMMENT >=> mask 
1 COMMENT-COHST ' = * mask 
I MAX-COHSTS.PERJLINE ’ = ’ NUMBER 
// typename and enum shall be defined together 
I MIX-WITH.TYPEDEF » = » mask 

// enum definition shall not be combined with var definitions. 
I MIX-WITH-VARS ' = ’ mask 

// enum definition shall not be combined with function 
// definitions/declaration. 

I MIX-WITH.FUNC ' = ’ mask 
I 1NIT.C0NSTS ’ = ’ mask 
1 DEFIHE.TAG mask 
| OPENJBRACE.POS »=» indent .opt ion 
I CLOSE.BRACEJPOS ’=' indent-option 
I CONST JSTART-POS ’ = ’ indent-option 
I CONST.CONT.POS ’ = » indent-option 


struct .rule-list : 

struct -rule-list ' ; ’ struct_rule 
I struct_rule 


struct .rule: 

MIX-WITH.TYPEDEF ’ = ’ mask 
i MIX-WITH.VARS ' = ' mask 
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// Combine struct /union definition with function 
// declaration/definition. 

I MIX.WITHJFUNC > = ’ mask 

// typedef for struct/union shall have typename for struct and 
// struct ptr. 

I TYPEDEF _PTR ’ = ' mask 

// union shall not have pointer fields combined with non 
// pointer type fields 
I PTR-ONLY-UNION ’ = ’ mask 
I COMMENT '=’ mask 
I COMMENT JFIELDS ’=’ mask 
\ COMMENT-BITFIELDS ’ = ' mask 
I UNSIGN .BITFIELDS ’=’ mask 
I STRUCT.FILE » = > mask 
I FIELDS -PER JDECL ’ = ' NUMBER 
I DEFINE-TAG > = ’ mask 
i OPENJBRACE _POS ' = ’ indent .option 
I CLOSE-BRACE.POS ' = ’ indent-option 
I FIELDS-START.POS ’ = ’ indent.option 
I MAXJFILEDS = NUMBER 


axray-ruleJList : 

array .rule-list ’ ; ’ array .rule 
I arrayjrule 


dim-list: 

dim_list V HUMBER 
I NUMBER 


array_rule : 

// Most significant dimension of external array shall not be 
// defined. 

MULL-FIRST-DIM ’=’ mask 

// Most significant dimension of initialized array shall 
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// not be defined. 

I INITJFTRST-DIM mask 
// Valid ops to be used with array vars. 

I VALID-OPS »(> op-list >)> 

// Dimension expression shall be a #defined expression 
I MAGIC JDIMS ’ = » mask 
I MAX-DIM-SIZE »(* dim-list »)’ 


opjrule-list : 

op-ruleJList * opjrule 
I op-rule 


opjrule : 

// Conditional expression of ternary operator shall inclosed 

// in parenthesis 

BRACKETED-TERNARY > = > mask 

// Nested ternary ops shall not be used. 

I NESTED -TERNARY mask 

// Relational ops etc shall be #defined 
| NAMED-OPS > = > >(* op-name-list »)’ 

// Spaces around a op 
1 OP -SPACES »(* op-space-list >)> 

t ARRAY JPORMAT NUMBER ’ [* NUMBER >3’ NUMBER 

// Number of spaces after a comma. 

1 COMMA-SUFFIX-SPACES NUMBER 
// Number of spaces after a semi-colon. 

I SEMICOLON-SUFFIX-SPACES > = > NUMBER 
I BRACKETED-SIZEOF ’ = ’ mask 
// Braces shall be on a line by itself 
I EMPTY JBRACEXINE > = > mask 


op-name-1 i st: 

opjaame-list * , 1 opname 
I op-name 
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opjname : 


I 

* ( * op.code * = 

’ STRING ’)’ 

op.space.list : 



op.space_list 3 

’ , ’ op_space 

i 

> 

op .space 


op .space: 

> 

op.code : 

1 ( 1 op.code 1 = 

PRIMARY 

* NUMBER 1 , > NUMBER ’ ) » 


BINARY 



UNARY 



ASSIGN 



1 CALL 



1 INDEX 



1 ARROW 



i *.• 



LNOT 

// Logical not 





PLUSPLUS 

MINUSMINUS 



UMINUS 

// unary minus 

; 

UPLUS 

// unary plus 


STAR 

// dereference 


ADDRESS 

CAST 

I SIZEOF 

II ft 


I *** // multiplication 

I 

i >V 

I » + > 

I * - * 
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// Max length of an external variable. 

I MAX_EXTERN_VAR_LENGTH = NUMBER 
I MAX-FILE_NAME_LENGTH >=’ NUMBER 
// full-length . length.of -extension 
I FILE_NAME_FORMAT ' = ' NUMBER ’ NUMBER 
I MINJIAMEJLENGTH > = > NUMBER 
// Text case of const type id. 

I CONST-CASE ’=’ case.option 
// Text case of enum constants 
I ENUM-CASE ’=’ case.option 
// Text case of #defined constants 
l HACRO-CONST.CASE ' = ' case.option 
// Text case of #defined constants 
I MACRO-FUNC.CASE ’ = ’ case.option 
// Text case of variable names 
I VARNAME.CASE ’ = * case.option 

// Text case of typedefed type names. 

I TYPENAME.CASE • = > case.option 
// Text case of function names 
I FUNCNAME-CASE * = > case.option 
// Text case of label names. 

I LABEL-NAHE-CASE ’ = ’ case.option 
I STRUCT-TAG-CASE ’ = * case.option 
I ENUM-TAG.CASE ‘s’ case.option 
// Max length subword. . / change of case is considered 
// as end of a subword. 

I MAXJSUB.WORDJLENGTH ’ = ’ NUMBER 
1 IAMING.STYLE ' = ’ CASE.CHANGE 
I NAMING-STYLE » = ’ UNDERSCORE 
I PREFIX .FUNCNAME » = ’ mask 
I PREFIX JIRGHAMES » = ’ mask 
I TYPEJ»REFIXS ’ = ’ ’(’ prefixJ.ist ’)’ 

I UNDERSCORE JST ART ' = * mask 


prefixJlist: 

prefix J.ist ’ , ’ type.pref ix 
I type-prefix 
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type-prefix: 

* ( * type 9 


9 STRING >)> 



Appendix B 


Sample Style File 


CODE-FILE 

{ 

HEADER. « YES; // File shall have a header comment 
BSJIL = NO; // back slash new-lines only in macros 
NOJtETORN = YES; // main shall return with exit call 
EXITJTOJDS = YES; // exit arg shall be OS defined value 
IFJEICLUDE = YES // idempotent file includes 

} 

FUHCJDEF 

{ 

MAXJLRGSJPERJLINE * 1; 

COMMENT JJEADER * YES; // function shall have a header comment 
DECL JSXTERM JVAR$ * NO; // extern var decl shall not be there 
USEJSNVP * NO; // envp command line arg shall not be used 
DEFJSTRUCT = 10; // struct /union shall not be defined 
DEFJtETJFYPE » NO; // return type shall be specified 
SINGLE-RETURN « NO; // function shall have a single exit point 
USEJTARARGS = MO // variable length args shall not be used 

} 

pp 

{ 

IICLUDE 

{ 

RELATIVE-FILEJIAME = YES 

>S 
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HACROJFUNC 

{ 

BRACKETED_ARGS = YES; // axgs shall be in parenthesis 
SEHICOLOK_AT_END = NO 

} 

} 

CONSTANT 

{ 

HEX-IHJ5IT.STATEMENTS = YES; 

DECIMALS = YES // only decimal constants shall be used 


{ 

COMMA-SUFFIXJSPACES = 1; 

NAMED-OPS = ( (== “EQUAL")); 

} 

STATEMENT 

{ 

IF 

{ // nested if shall be braced completely 

BRACED JIESTED.IF = YES; 

}; 

USE.GOTO = NO; 

NULL-ISJPTR = YES; // NULL shall be used as a pointer 
MULTIPLE JUNC.CALLS = NO; // Only one function call 
CHECK-SYS-CALL = YES; 

CHECK.MEM.CALL = YES; 

END-COMMENT = YES; 

NULL-BODY-POS = (ALIGN, i); 

DEFAULT-CASE = YES; // switch shall have a default case 

} 

EXPRESSION 

{ 

PTRJDPS » (+, -); // ops to be used with ptr type vars 
SIGNED JOF-COMP ARE = YES; // EOF shall be compared with signed type 
CALL 
{ 
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BIIDJSPACES * (SPACES, 1); 

MACRO-CALL -BAD.OPS = (++, — ) // 0 ps not to used 


} 


}* 


LOGIC 




} 


BAD-OPS = (=, +=, *=, • = , /=, -=, «=, »=, y, = ) ; 

DEFAULT .FAIL * 10 // conditional expression shall have 
// at least on relational op 


DDD 


COMMEXT JST ATIC-V A RS ■ YES; 

DEFAULT JIT.TYPE ■ 10; 

MAX-VARS-PERXIXE = 1; 

MAIXIIES * 1; 

STRUCT -FILE = YES; // struct definitions shall be kept in a separate file 
STRUCT 


{ 

MIX-WITH-TYPEDEF = YES; // typedef of struct shall be combined 

// with struct definition 


MIX-WITH-VARS * 10 

)i 

ARRAY 

{ 

HAGICJDIHS * HO // dimension expr shall be #defined expr 

} 

} 

IAMB 

{ 

XAKIIG-STYLE = UNDERSCORE; 

COIST-CASE * UPPER; 

FILEJAMEJFORMAT = 11.3; 

PREFIX-ARGHAMES = YES; 

UIDERSCOREJSTART = HO 

} 
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Appendix C 

Sample Style Violation Warnings 


CSA Warning:test/tl.c:l:Missing file header 

CSA Warning : test / 1 1 . c : 5 : macro constant name in improper case 

CSA Warning: test/t l.c:9: UnCommented global static var 

CSA Warning : test/tl ,c:ll :UnCommented global var 

CSA Warning : test/t l.c: 15 :enum constant name in improper case 

CSA Warning: test/t l.c: 15 : Insufficient spaces after , 

CSA Warning : test/t 1 . c : 24 : typename in improper case 

CSA Warning: test/t l.c: 33: Function name starts from wrong position 

CSA Warning: test/tl ,c:36 :Function declaration inside function 

CSA Warning : test/tl .c:38: Uncommented local static var 

CSA Warning: test/t l.c: 39: Var definition spans over lines 

CSA Warning: test/t l.c: 39: More number of definition in a single line 

CSA Warning: test/t l.c: 53: Mo re number of definition in a single line 

CSA Warning: test/tl. c:59: Insufficient spaces after if 

CSA Warning: test/t l.c: 65: Invalid op = in conditional expression 

CSA Warning: test/t l.c: 65: else if position invalid 

CSA Warning: test/t l.c: 60: No braces around nested if statement 

CSA Warning: test/t l.c: 69 insufficient spaces after for 

CSA Warning: test/t l.c:74: Insufficient spaces after while 
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Appendix D 
Glossary 


ARG : argument 

BS-NL : backslash newline pair 

C-CSC : C Coding Style Checking 

C-SSL : C Style Specification Language 

CALL : call expression 

CONST : constant 

CONT : continuation 

DDD ; Data declaration and definition 

DECL : declaration 

DEF : definition 

EOF : end of file 

EXPR : expression 

FUNC : function 

GNU : Generally not unix 

INDEX : index expression 

INIT : initialize 

LOGIC : logic/conditional expression 

OP : operator 

OS : Operating system 

POS : position 
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PP : preprocessor 

PTR : pointer 

RET : return 

STD : standard 

SYS : system 

VAR : variable/identifier 
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